IBIS Macromodel Task Group

Meeting date: 29 September 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad noted that he had removed two BIRDs from the "Pending BIRDs" list in the
  ATM Agenda.  BIRD 157, Parameterize [Driver Schedule], had been voted down in
  the Open Forum meeting.  BIRD 178, Specifying Buffer Directionality for AMI,
  had been approved by the Open Forum and is now part of the released IBIS v6.1
  specification.
  
- Arpad noted that we may need to cancel the ATM meeting the last week in
  October because of people traveling for the IBIS Summit held at EPEPS.  He
  said this would be finalized during upcoming meetings.
  
- Ambrish mentioned that work commitments had kept him from making progress on
  the Back-channel proposal (BIRD 147).

--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- Arpad to work on the next revision of the Info, Out, InOut BIRD draft based on
  the language changes proposed during last week's discussion.
  - Done (see discussion below).

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Todd: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Item #6: Info, Out, InOut BIRD draft.
- Arpad: [sharing some new language proposals he had emailed to the reflector]
  - Today I would like to answer the following question:
    - What type of special parameters should be listed in this new Reserved
      parameter?  Should we list only those parameters without which the model
      would be completely broken, not able to perform even the basic IBIS-AMI
      functionalities, or should we also list those parameters that are needed
      for "above and beyond" normal features?
  - I believe Walter's preference was to list both types, even new features.
- John: Could we start with this proposed definition? [following]
  - Any Model Specific parameter that requires the tool to do anything other
    than just get the user's input (provide a value) or display it to the user
    should be listed in this new keyword.
- Mike L: That sounds like it lines up fairly well with Walter's proposal.
- Radek: I think we've agreed to that several times.
  - John's way of phrasing it is good.
- Arpad: I want to discuss the word "requires".
- John: Requires in order for the model to function as the model maker intended.
- Bob R: If the model maker wants the features used, the parameter(s) should
         be listed.
- Walter: Requires is not a good word here.
  - Any Model Specific parameter for which the model maker expects the EDA tool
    to do something other than allow the user to select a value or display
    the value should be listed.
  - We've all said the same thing several ways.
  - I think we are all in agreement.
  - We don't need any requirements on what bad things will happen, etc.
- Arpad: Okay, this decision has been reached.
  - Given this decision, the follow on question is:
    - Would it be useful to have an indicator for each of the special parameters
      to indicate whether it is part of a new feature or required to get proper
      results out of standard simulation flows?
  - It sounds like it might be useful to have a "severity" indicator.
- Walter: The information would be useful.
  - It should be given to the user as the description field of the parameter.
  - The model maker should describe what the parameters do.
  - We should leave this to the model maker.
- Radek: I think the original agreement was not to complicate things with this
         indicator parameter.
  - However, now that the new Reserved parameter has Format Table, it would be
    easy to add another column.
  - It might be easy to add another bit of useful information.
- Arpad: I agree.
  - A second column would be parseable, as opposed to description field text.
  - The tool could then decide, when it doesnt recognize the name of a special
    parameter, whether it can perform the basic AMI simulations or not based on
    the severity indicator.
- Discussion: Do we need a severity indicator for non-standard parameters?
  Participants understood the value of the information Arpad's proposal was
  attempting to provide, but there was disagreement about whether the proposal
  would work in practice.  Bob R. agreed with Walter's position that it was an
  unnecessary complication, and suggested that there would always be a grey area
  between any two defined severity levels.  Todd stated that he was worried that
  we were already asking model makers to list their non-standard parameters, and
  asking them to now flag them as the "critical" type might be a bridge too
  far.  Tstone models were again introduced as an example.  Todd suggested that
  tstone might not be flagged as critical, since the workaround was well
  documented and easy.  Radek countered that the workaround might not be trivial
  depending on how the IBIS Model had been formulated.  Bob M. noted that as a
  model maker who had released tstone models he would list it as critical to
  ensure the users were alerted.  John, Bob M., and others noted that if we were
  debating the way to characterize tstone models then it would be hard to expect
  model makers to uniformly characterize their parameters.  Arpad felt the issue
  could be addressed by properly defining the criteria for the severity levels
  in the spec.  He also suggested we might use a term other than severity
  if that sounded too harsh.  Ambrish reiterated that this entire BIRD was all
  voluntary on the model makers' part, and adding further indicator fields would
  be an unnecessary complication.
  Todd suggested that we have a vote to see where people stood on the topic.
  Walter suggested that each person vote, as opposed to each company, since this
  was a non-binding vote just to gauge the opinion of participants.  Arpad and
  Mike L. noted that the vote was not official, and Arpad phrased the vote,
  "Should we add a severity parameter for the non-standard parameters?"
  Results of Participant Vote:
  Dan Dvorscak      No
  Curtis Clark      No
  Bob Miller        No
  Ambrish Varma     No
  David Banas       No
  Michael Mirmak    Abstain
  Radek Biernacki   Abstain
  John Angulo       No
  Arpad Muranyi     Yes
  Randy Wolff       Abstain
  Walter Katz       No
  Todd Westerhoff   No
  Mike LaBonte      No
  Bob Ross          No
  
  Totals:
  No      - 10
  Yes     -  1
  Abstain -  3
  
- Arpad: The feelings of the group seem pretty clear.

- Arpad: I would now like to review the proposed language.
- Ambrish: Will this have an impact on the parser?
- Bob R: The parser will be cross referencing names from the new parameter to
         make sure they exist in the Model Specific parameters.
- Discussion: Parser handling of the new parameter.
  Ambrish and Arpad suggested that the parser should issue a warning
  if the new parameter appeared at all, and an error if the new parameter
  contained the name of a parameter that did not exist in the Model Specific
  section.  Bob R. suggested that the parser should issue a note and warning
  respectively in those two cases.  Bob R. asked that any parser handling
  requirements be documented in the "Background information:" section of the
  BIRD and not in the text of the actual BIRD (spec).  Mike LaBonte agreed
  with this, and suggested that these topics might be handled in the IBIS
  Quality Group.

- Arpad: Thank you all for joining.

-------------
Next meeting: 6 October 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
